数据工程在腾讯CDC的演进

文章概览

本文共有3766字，大概需要7分钟阅读。

前言

在很多产品的迭代过程中，我们可以通过构建系统的指标体系对产品发展进行持续评估。特别地，在用户调研类服务产品中，我们需要持续地、细化地同时对B端和C端用户进行观察；随着产品功能的增加和用户群体的扩展，报表的数量在不断增加，团队同学对数据的也需求越来越多。

问题分析

不同人对数据的需求是不一样的，或者说，不同同学对同一份数据的不同指标组有不同的价值认可。

1.我们的交互同学更多地会参考大盘的“用户习惯”，使用某个问卷题型的比例来作为设计方案的数据支撑；

2.开发同学更多地会关注这个数据引发地一些性能（问题），架构指标等；

3.产品同学会非常关心某个上线项目的入口流量，转化率相关指标；

4.运营同学关注的方面更为通用，除了大家都关注的北极星和护栏指标，他们更会关心用户在使用上的一些点位问题，单个/单批用户的运营策略转换问题。

虽然上面只提到4个笼统的数据场景，但是其实我们由此产生的数据图表、SQL模板甚至是需求单已经有很多，于是我们从规范和流程上看到了一些问题：

1.我们要如何快速找到我们指标对应的底层数据？当时一个关于「活跃用户」在团队版中的表现的下推分析，后面还加上了登录渠道的多维分析，我们甚至开了一场会去校对口径 ;

2.关于口径，我们如何确定什么数据是对的呢？不同的数据开发同学开发的报表相差很大；

3.开发同学有非常美好的想象力，一句超凡脱俗的SQL不仅在当前的架构下得不出结果，甚至会拖垮其他依赖的组件。

让用户简单地找到正确的数据，需要把数据按照层级顺序摆放在合适的位置并且登记在册，在当时的时间点下，开始构建数据业务的数据仓库当然是最好的选择；我们在数仓开始之初时反思，为什么口径、数据、校对总是不能被一次敲定呢？后来我们发现，我们做这个需求的过程：从口径的描述、SQL的开发执行到出库展示整个过程没有一个地方是可以被review的。而对复杂数据量的支持，其实就是架构该升级了，单点的ES无法支持多场景的adhoc。

数仓基建与维度建模

在做这个事之前，我问组里的同学：“我们有什么数据能够支持我们做数据分析？”，清一色的回答：“ES里的后端Event日志，前端上报的Pageview和埋点，业务DB中的表”。确实我们早期就有比较统一的基于事件流的日志格式和较为完备的前端埋点组件，但是我们还是没法回答我们拥有的数据如何支持我们完成某些需求的问题。只有我们把我们拥有的数据的具体能力和表现形式放出来，我们才能真正知道我们拥有的是什么，数据才能真正地从数据存储变成数据资产。

明确数据表

上图显然就是我们数仓初期ODS到DWD的一层规划，这里我们更希望引入产品同学来对齐我们现有的数据资产，以便在后续数据需求的沟通上能够明确哪些数据能为我们所用，我们有哪些底层数据需要再去补齐。明细表一般存在于流式数据中，带有时间属性，一般用于一段时间内的指标计算。

同理，我们把存在业务DB中的数据平移到数仓中，这些数据表本身经过了不错的数据建模，我们将我们拥有的表保留退化维度同步到数仓，我们就得到了DIM层(块)。维度表一般不带有时间属性，用于关联做维度分析。

业务总线矩阵构建

把动态的明细数据和静态的维度数据相互交叉，就得到了我我们数仓的底层应用「业务总线矩阵」。在这个笛卡尔坐标系里的每一个点或者一条线都有它的业务意义。比如我们通过交叉「登录明细」 和「团队信息」，我们就能得到「团队登录」的明细；通过交叉「登录明细」、「团队信息」和「用户登录渠道」（2维度1明细），我们可以得到「分渠道的团队登录」明细，这是一种维度细分统计的构建；通过交叉「登录明细」、「团队信息」和「提交答卷明细」（1维度2明细），我们可以得到「团队版登录且答题」明细，这是行为组合（细分）。

至此，我们能够清楚地认知数据可能会在哪个位置发挥什么作用，下一步要解决的是我们该怎么找到我们的数据这个问题。

元数据管理

为了解决“我们有什么数据”这个问题，我们决定接管数据的入口，把开发过程中生成的数据表按照数据的生命周期命名打上标签。 

问卷的业务数据库里有百余张表，其中大约有近4成为维度表，需要拆分成明细的点位或者日志会随着业务发展主键膨胀，业务总线矩阵也会主键变成一张大网，失去可检索性。事实上，我们对数据的需求是有描述性的，比如想看“这周问卷的新增明细”，我们并非记住一串冰冷的文字，我们更希望能把「1周」，「问卷」转换成描述条件作为我们元数据的检索入口。 我们支持了Superset从表comment、字段comment中检索的需求，把想要的关键字按照关键字检索匹配到正确的数仓入口。

数据血缘

在我们接管了数据产生的入口后，我们把用户调用数据资产的记录同样采集了起来。基于一套low code配置化调度任务，我们在为开发同学提供分区筛选、数据量评估、sql执行、执行结果质量校验和下游写入的能力的同时，我们更在配置化的Spark启动入口处植入了血缘上报，当一个任务被成功执行计算后，我们采集了数据的流向和数据流动比例。

有了数据血缘后，在一份数据出现分歧时，他的数据量和执行计划都是可以被review的，从数据读入和写出的量级波动情况可以相对容易地追溯到原因，但是目前还没有做成波动归因。

到这里，我们的数据开发链路的不确定性只剩下了口径确认和变更。我们通过将指标组（一般是单指标多维度）命名，分配给数据开发同学，确定产品负责人和开发负责人。这个顺便解决了我们之前无法追溯报表错误不知道该找哪位同学来看的问题。开发完成后挂靠在某个具体的数仓表上，实现数据需求到数据开发到底层计算的全链路记录，当数据出现问题或需要修改时，则整个链条上的负责同学都会有感知，确保发起的修改能够被所有相关的（特别是下游的）数据同学review到。

数据架构

规范的事情暂时能跑了，在只有我一个人力的情况下继续大力度地做进一步数据治理可能并不是当下最急需的，在场景分析中提到的问题，我们还有关于开发最重要的一个问题——当下的数据架构需要升级。为了回答这最后一个问题，我们希望把昂贵的ES储存费用转投到能面向更大型分析场景的数据架构上。

在之前，部门内所有的分析都有ES或者ELK套件承担，从20年开始性能和钱包都陆续见到了瓶颈。目前部门数据平台内走的是以流式分发为主的Lambda架构，由下游需求决定数据是否从实时层沉降到离线层。维度数据会存在离线层，事实明细数据会广泛地存在于实时层，这是基于下游有时延要求高，维度要求低的场景，只需要做简单的指标聚合，附带退化维度写出即可。

和Lambda架构不同，我们的低时延分析需求更多地由近实时分析层承担，针对不同需求，我们尝试过很多不同的组件，根据不同的使用场景，比如全文查找、强聚合、上下文分析等等，我们会选择不同的组件。基于不同的组件，我们在上层有去尝试做不同的应用实践。

应用实践

机器学习

在机器学习方面，腾讯问卷有基于用户答题的行为，构建用户答题的时间序列，得到一个评估用户答题认真度/可信度的评估模型，目前这个工具已经上线到样本库填答的红包发放鉴别能力中，提供给投放者对回答可信度和总体回答质量做相应参考。

在最早期我们通过ES去查找单份答卷用户在答题过程中的所有用户行为埋点数据来构建序列数据进行预测，将预测结果写入DB；在近一年中，我们把查询数据源经过计算清洗后写入按问卷和用户为索引的ClickHouse数据源中，同时将服务与线上服务解耦，使用kafka来进行通信；最后配置了消费监控和写入监控，使这个服务成为一个单独维护的组件。以牺牲少许的实时性为代价大幅提升了预测速度和可用性。

实时风控

基于实时层的数据聚合分发能力，我们在问卷系统中逐步搭建了一套对问卷维度进行风控的系统。在最早期的设计中，实时层基于小时间段窗口触发计算，从明细数据流读取计算到写入下游系统之间的误差能够控制在秒级，支持了下游规则引擎的实时特征数据检索。

在架构上，风控模型走的是全实时数仓链路，从Kafka明细中读出前端上报信息和后端收集答卷的日志，在Flink中做实时的多窗口聚合写入到下游的数据组件。在前期选型中，业务侧希望能够具有实时调用和短时间指标回溯的能力，同时希望系统组件能够相对轻，能从云上购买，最后我们选定了Kafka作为业务侧实时接收窗口聚合结果的组件，PostgreSQL作为小时间段的回溯组件来构建线上的风控分析。

AB实验

目前，我们已经在SaaS平台内对文案显示、用户逻辑等多方面做了很多次AB测试，通过pv上报的曝光和event埋点的转化分析，能够实时构建单个用户的转化行为；相同地，我们会对实验时间范围内的数据使用ClickHouse构建用户RBM，分析不同用户在不同实验命中的表现情况。

总结

通过补齐一些基本的数据架构和数据规范，目前我们在数据驱动的实践上已经走出了一条自己的路。随着用户调研类组件的发展、用户分析需求的增加，其分析能力也会随之增强，越来越多的数据能力正在沉淀成底层功能加入到SaaS服务侧。

---

快乐工作，快乐生活

Happy work , Happy life

/

Join us